Using Perforce to Facilitate Agility

As software development evolves toward more agile methodologies (SCRUM, XP, RUP), engineering best practices become key to ensuring the delivery of high quality software that best meets a customer’s needs. This paper will briefly introduce agile methodologies and the best practices that facilitate successful agile implementations. It will focus on software configuration management (SCM) practices especially that of continuous integration using a team at Bio-Rad Laboratories as example. It will focus on the details of a Perforce enabled system. The history of software development is delineated by various process practices – waterfall, spiral, and now agile. What exactly is Agile? Why is it the way to go according to a growing number of practitioners? Agile isn’t actually new. The principles that underlie it have been practiced and developed over the last 100 years. They are driven by the desire to manufacture things more efficiently while meeting customers’ needs better. What makes an agile implementation a success? Why is software configuration management (SCM) so important to a successful agile implementation? These questions will be answered below as I examine in more detail an implementation of SCRUM – a current agile methodology – by Bio-Rad’s mass spectrometer data aggregation and analysis software development team. I will outline how we use Perforce to bring predictability to our product and how it helps us to work daily to eliminate chaos. Agile as a software development methodology has a longer history than is commonly understood. The tenets of agile – the things that make agile, “agile” – have been a part of lean manufacturing practice for most of the last century. Beginning with Henry Ford and modern assembly line manufacturing, industrialists have been attempting to eliminate waste and make things more efficiently. This was first driven by profit motives but evolved into a desire to delight customers. The two are not at cross purposes and in fact build on each other to help to create a better overall product. The broadest and most often cited application of agile principles in large scale manufacturing is that developed by Taiichi Ohno, Shigeo Shingo and Eiji Toyoda at Toyota. These principles and practices are collectively known as the Toyota Production System (TPS) and evolved into the movement of “Lean” manufacturing. The practices embodied by TPS include: continuous process flow, periodic reflection, building quality in, publication of control measurements, and empowering team members to control and improve work product, process and themselves. TPS and Lean manufacturing began to be examined and adopted by American manufacturers during the 1980’s. Coincidentally, software was just beginning to be considered a formal discipline. During this pre-Internet enabled era, software was most often found as a component on larger projects. Projects that were often managed using what is called the “waterfall” or gated development process. Waterfall processes depend fundamentally on the idea that what is required at the end of a project can be determined at the beginning. Stages of development follow one after the other with little feedback between them. The development phases are commonly: specification, design, implementation, test and deployment. Since there is little feedback between the stages, each stage is driven to completion and then handed off to the next set of resources. Change becomes increasingly expensive the later it is introduced in the process. Any change must navigate the entire process again. Change is therefore resisted. Waterfall or gated processes work well in deterministic systems where important decisions can realistically be made up front. Software, as we have discovered, is often not deterministic and can, in fact, meet today’s rapidly changing business needs better if it is allowed to respond to change dynamically if it is allowed to be more “agile”.